home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1157 < prev    next >
Internet Message Format  |  1994-08-27  |  4KB
  1. Date: Sat, 30 Jul 94 01:36 CDT
  2. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  3. To: gem-list@world.std.com
  4. Subject: RE: Re: Scope of an APP_DEFS file
  5. Precedence: bulk
  6.  
  7. ========================================================================
  8. This is all up for debate but things like that are usually saved in the
  9. program's own preferences file, and I take it that APP_DEFS conforming
  10. programs will not use their own preference files: Am I right or wrong?
  11. ========================================================================
  12.  
  13. Uhh .. depends.  If there is alot of very specific stuff, like if you
  14. want a persistent application (when you run the program it returns itself
  15. to the EXACT state it was in when you quit it) then I would say that
  16. some things should be left out of app-defs.  For user "preferences"
  17. all of that should be in app-defs.
  18.  
  19. ========================================================================
  20. file with things such as Update Windows in Background, Show Spectrum
  21. Analyser and Playback Quality.
  22. ========================================================================
  23.  
  24. Hmm .. you could even make those global and let all programs use the
  25. same playback speed and such.
  26.  
  27. ========================================================================
  28. Myself I do think a program should be able to update its lines in an
  29. APP_DEFS file, otherwise you would have to exit the program before you
  30. could save changes; I'd rather use my own prefs file for most things if
  31. that was the case.
  32. ========================================================================
  33.  
  34. Yes, but search the file backwards for the proper match, and search
  35. for the specific, so wildcards in the file will match.  For example,
  36. search for StormTracker.PlayFrequency from the end of the file.
  37.  
  38. This will catch the same option as searching from the beginning of
  39. the file for the last match (which you could also do, but reverse
  40. search may be faster).  The idea is that if you have :
  41.  
  42.   *.PlayFrequency: 25
  43.   StormTracker.PlayFrequency: 12
  44.  
  45. Then the application specific entry should be changed, but if you have
  46.  
  47.   *.PlayFrequency: 12
  48.  
  49. And no applicaion specific entry, change the global one.
  50.  
  51. I'm sure some people would say that you should create an application
  52. specific entry, others would say to pop-up an annoying alert box.
  53. I think that if the user wanted separate entries, they would already
  54. be separate, so change the global.
  55.  
  56. I think the app-defs editor that has been proposed, should accept
  57. a command line parameter to filter out all but that particular
  58. apps settings, with some toggle to include or exclude globals.
  59. Then you can just call it from within your app.
  60.  
  61. ========================================================================
  62. The .Xdefaults file's way of specifying shift keys if very sensible:
  63. ========================================================================
  64.  
  65. What I wanted was thus:
  66.  
  67.  *.Command.key: <cntl>
  68.  StormTracker.Quit.key: Q
  69.  StormTracker.GotoEnd: Home
  70.  StormTracker.PlayFrequency: 12
  71.  
  72. And you could add stuff like :
  73.  
  74.   STalker.Command.key: <alt>
  75.  
  76. But adding that line hasn't changed *.Quit.key or *.Open.key or any
  77. of the others.  It did make STalker use ALT O for open instead of
  78. CONTRL O for open though.  Changing command keys just means playing
  79. with the returned bits for evnt_multi a little differently.  Its
  80. not hard to implement at all.
  81.  
  82. ========================================================================
  83. Which is also a lot more readable
  84. ========================================================================
  85.  
  86. Q is VERY readable, and since 90% of the apps will not use ALT and CNTRL
  87. at once it makes alot of since.  If you use ALT and CNTRL, then setting
  88. such a variable would be possible, but not easy (maybe swap meaning of
  89. CNTRL and ALT? in any case specify that the key is different).
  90.  
  91.